feat: reverse index scans and statement-scoped write visibility - #384

What problem does this PR solve?

Issue link:

1. Prepared execution cloned the whole plan per run, and executors copied operator fields.
2. ORDER BY ... DESC / MAX always needed a full index scan plus sort/TopK; TPC-C Order-Status got slower as orders grew.
3. Correctness bug: a scan could re-read rows written by the same statement. On LMDB, UPDATE t SET id = id + 1000 WHERE id > 3 updated rows multiple times (or until integer overflow), and INSERT INTO t SELECT ... FROM t duplicated rows. RocksDB had the same bug inside explicit transactions.
4. Memory storage cloned the entire key range at scan start.

What is changed and how it works?

• Borrowed plans: executors borrow &LogicalPlan operators instead of copying them; prepared statements no longer clone the plan. Parameters are bound lazily in IndexScan.
• Reverse index scan: range_rev on all storages; the optimizer reverses an index scan when the whole required order is reversed (NOT NULL columns only, never below a Limit). EXPLAIN shows Reverse.
• Statement stamps: every tuple/index value gets an 8-byte suffix with the id of the statement that wrote it; scans skip entries with the current statement's stamp. Stamps come from the LMDB txn id, the RocksDB sequence number, or a memory counter, and are only allocated for statements that both scan and write (bulk INSERT ... VALUES uses 0).
• Storage iterators: LMDB/RocksDB iterators are driven by explicit step enums; LMDB remove_range reuses the scan; memory iterates the BTreeMap lazily.
• Tests/tooling: SLT runs on LMDB (no longer builds RocksDB); the TPC-C runner pins to the fastest P-core; README trimmed.

Code changes

• Has Rust code change
• Has CI related scripts change

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Note for reviewer

• On-disk format changed (stamp suffix): data written by 0.4.0 cannot be read. Version bumped to 0.4.1.
• Performance (TPC-C LMDB, 60 s, pinned to cpu8, 3 rounds): TpmC about -2.5% vs main; Order-Status p90 about -15% (51→43 µs). With the stamp check disabled the result is the same, so the cost comes from elsewhere in the change, most likely the extra 8 bytes per value (not profiled). RocksDB Delivery p90 dropped about 34% in a separate short run.
• Tests: all unit tests pass; SLT 197/197 on LMDB; regression cases in update.slt / insert.slt and a shared explicit-transaction test on memory, LMDB, and RocksDB (pessimistic + optimistic) fail without the fix.
• unsafe: PlanKeeper, the memory iterator value pointer, mdb_txn_id, and the RocksDB snapshot sequence number, each with a SAFETY comment. Not run under Miri.
• Known gaps: equality point lookups (Range::Eq hits) are not filtered by stamp; table-level PRIMARY KEY (a, b) does not mark columns NOT NULL, so reverse scans don't apply there.